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(54) Packet network interfacing 

(57) . A method of establishing a tunnel across an 
IPv4 domain for the transport of packets from a source 
host on one IPv6 domain to a destination host on anoth- 
er IPv6 domain, there being respective interfaces be- 
tween the IPv4 domain and the IPv6 domains. The 
source host sends a normal IPv6 address request to its 
locai DNS server, which relays it to an IPv6 name server 
in the other IPv6 domain. The response message, con- 
taining the true IPv6 address of the destination is re- 
ceived at the remote interface, which appends to the re- 
sulting protocol converted DNS response message a 
first additional record containing the true IPv6 address, 
and a second additional record containing the IPv4 ad- 
dress of that interface. Upon receipt at the near inter- 
face, the additional records are stripped off, their con- 
tents stored in an entry of a table, and the true IPv6 ad- 
dress written into the address record of the resulting 
IPv6 DNS response message. When the near interface 
receives a packet from an IPv6 host, it checks whether 
the destination address matches an entry of its table, 
and if so sends the packet to the encapsulator together 
with the IPv4 address of the remote interface. The re- 
mote interface extracts the source address and the ad- 
dress of the encapsulating interface and stores these in 
an entry in its corresponding table for use in encapsu- 
lating return packets to the source. If, however, the des- 
tination address is recognised as being of IPv4-compat- 
ible or lPv4-mapped format, the packet is sent to a pro- 
tocol converter. 
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Description 

[0001] This invention relates to the establishment of 
a tunnel entrance for packets crossing the border be- 
tween a first network operating in accordance with a first 5 
transmission protocol and having network addresses in 
accordance with a first addressing convention, herein 
referred to as first type addresses, and a second net- 
work operating in accordance with a second transmis- 
sion protocol and having network addresses in accord- 
ance with a second addressing convention, herein re- 
ferred to as second type addresses, and relates partic- 
ularly, but not exclusively, to communication between 
hosts in respective Internet Protocol version 6 (I Pv6) do- 
mains separated by an Internet Protocol version 4 (IPv4) 
domain. 

[0002] Herein, the terms packet and message are 
used interchangeably and have the same meaning, and 
the term Internet domain is used as a specific example 
of a network. 

[0003] In Internet technology, it had become apparent 
that the initial transport protocol, IPv4, needed to be en- 
hanced, principally to increase the available address 
space and add a hierarchical address structure. The re- 
sult was I Pv6 which has a simplified header format com- 
pared with IPv4, but which uses 128 bit addresses as 
compared with 32 bit addresses used in IPv4. 
[0004] Readers wishing to have an overview of this 
general area might like to access a list of Internet-Drafts, 
which are working documents of the IETF, at httpV/www. 
ietf. org/1 id-abstracts.txt, and a particularly relevant 
document is "A Guide to the Introduction of IPv6 in the 
IPv4 World" <draft-ietf-ngtrans-introduction-to- 
ipv6-transition-01 .txt>, also referred to as "Guide to IPv6 
Transition". 

[0005] As mentioned, the present invention relates to 
tunnelling. Known tunnelling techniques are of two 
types: configured and automatic. 
[0006] A configured tunnel is created by manual con- 
figuration of a tunnelling interface between an IPv6 do- 
main and an IPv4 domain such that all packets received 
from the IPv6 domain are encapsulated in IPv4 packets 
addressed to a specific tunnel end point, i.e. the tunnel- 
ling interface between the IPv4 domain and the remote 
IPv6 domain containing the destination IPv6 host. 
[0007] An automatic tunnel on the other hand does 
not need manual configuration: the tunnel end points are 
automatically determined. Several automatic tunnelling 
mechanisms are currently in development within the 
IETF, these being known in the art as, 6over4, 6to4, Dy- 
namic Tunnelling, and Tunnel Broker. 
[0008] For more detailed information on 6over4 the 
reader can obtain from the IETF, the document known 
as RFC2829, or any variant thereof, Transmission of 
IPv6 over IPv4 Domains without Explicit Tunnels", by B. 
Carpenter and C. Jung, March 1999. 
[0009] For more detailed information on 6to4 the 
reader can obtain from the IETF, the document known 



as draft-ietf-ngtrans-6to4-02.txt, or any variant thereof, 
"Connection of IPv6 Domains via IPv4 Clouds without 
Explicit Tunnels", by B. Carpenter and K. Moore. 
[0010] For more detailed information on Dynamic 
Tunnelling the reader can obtain from the IETF, the doc- 
ument known as draft-ietf-ngtrans-dti-OO.txt. 
[0011] For more detailed information on Tunnel Bro- 
ker the reader can obtain from the IETF, the document 
known as draft-ietf-ngtrans-broker-OO.txt. 
[0012] These known automatic tunnelling mecha- 
nisms use a variety of techniques to enable the tunnel 
to be automatically established: 

• 6over4 Multicast 

• 6to4 Special IPv6 addressin which thetop lev- 
el aggregator (TLA) contains an identifier for the 
6to4 tunnelling mechanism, and the next level ag- 
gregator (NLA) contains the IPv4 address of the 
tunnel end point 

• Dynamic Tunnelling via DNS 

• Tunnel Broker www based tool 

[0013] In accordance with a first aspect of the present 
invention, there is provided a method of establishing a 
tunnel from a first interface between a first network and 
a second network to a second interface between the 
second network and a third network, the first and third 
networks operating in accordance with a first transmis- 
sion protocol and having addresses in accordance with 
a first addressing convention, and the second network 
operating in accordance with a second transmission 
protocol and having addresses in accordance with a 
second addressing convention, the tunnel being for the 
transport of messages from a first host on the first net- 
work to a second host on the third network, the method 
comprising the steps of: 

sending from the first host an address request mes- 
sage in accordance with the first transmission pro- 
tocol, referred to herein as a first type address re- 
quest message, containing the name of the second 
host; 

upon receipt of the address request message at a 
name to address conversion system of the third net- 
work, returning an address response message in 
accordance with the first transmission protocol, re- 
ferred to herein as a first type address response 
message, and containing the address of the second 
host in a response address field; 
upon receipt of that first type address response 
message at the second interface, 

converting it to an address response message 
in accordance with the second transmission 
protocol, referred to herein as a second type 
address response message, and 
augmenting that converted second type ad- 
dress response message by fields respectively 
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containing the address of the second interface 
in accordance with the second addressing con- 
vention and the address of the second host in 
accordance with the first addressing conven- 
tion; and 5 

upon receipt of that augmented that converted sec- 
ond type address response message at the first in- 
terface, 

10 

converting it to a first type address response 
message, 

retrieving the contents of the augmenting fields, 
storing at the first interface a mapping of the 
retrieved address of the second host and the is 
retrieved address of the second interface for 
use in encapsulating messages from the first 
host addressed to the second host, and 
replacing the content of the response address 
field of the resulting first type address response 20 
message by the retrieved address of the sec- 
ond host. 

[0014] Preferably, for establishing a tunnel in the re- 
verse direction for the transport of messages from the 25 
second host to the first host, the method comprises the 
further steps of: 

upon receipt at the first interface of a message from 
the first host addressed to the second host, encap- 30 
sulating that received message in accordance with 
the first mapping; and 

upon receipt of the encapsulated message at the 
second interface, 

35 

un-encapsulating that received encapsulated 
message, 

retrieving from the encapsulating header the 
address of the first interface in accordance with 
the second addressing convention, *o 
retrieving from the un-encapsulated message 
the address of the first host in accordance with 
the first addressing convention, and 
storing at the second interface a mapping of the 
retrieved address of the first host and the re- *s 
trieved address of the first interface for use in 
encapsulating messages from the second host 
addressed to the first host. 

[0015] There may be included the steps of setting a so 
time to live for a said stored mapping, and rendering that 
stored mapping unuseable upon the expiry of the time 
to live, preferably deleting that stored mapping. 
[0016] In accordance with a second aspect of the 
present invention, there is provided a method of sending ss 
packets from a first host on a first network via a second 
network to a second host on a third network, the first 
and third networks operating in accordance with a first 



transmission protocol and having addresses.in accord- 
ance with a first addressing convention, and the second 
network operating in accordance with a second trans- 
mission protocol and having addresses in accordance 
with a second addressing convention, comprising the 
steps of: 

establishing a tunnel from a first interface between 
the first network and the second network to a sec- 
ond interface between the second network and the 
third network in accordance with the method of the 
first aspect of the present invention; 
upon receipt by the first host of the resulting first 
type address response message from the first inter- 
face, retrieving the content of the response address 
field; 

generating one or more packets for transmission 
having a header including source and destination 
address fields, the source address field containing 
the address of the first host, and the destination ad- 
dress field containing the retrieved content of the 
response address field; 

sending the or each generated packet to the first 
interface; 

for the or each said generated packet received by 
the first interface, accessing the stored mappings in 
accordance with the destination address of the re- 
ceived generated packet, 

retrieving the stored interface address of the 
mapping whose retrieved host address match- 
es the destination address of the received gen- 
erated packet, 

generating an encapsulated packet having a 
payload formed by the received generated 
packet, and having a header including source 
and destination address fields, the source ad- 
dress field containing the address of the first in- 
terface, and the destination address field con- 
taining the retrieved interface network address, 
sending the encapsulated packet to the second 
interface; and 

for the or each encapsulated packet received by the 
second interface, un-encapsulating the received 
encapsulated packet to recover the original gener- 
ated packet forming its payload, and 

sending that recovered packet to the second 

host. 

[00171 There may be included the step of storing the 
retrieved content in association with the name of the 
second host. 

[0018] There may be included the steps of setting a 
time to live for the stored retrieved content, and render- 
ing that stored retrieved content unuseable upon the ex- 
piry of the time to live, preferably deleting the stored re- 
trieved content. 
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[0019] Protocol converters are known for enabling an 
IPv6 host to send messages to an IPv4 host. When a 
new IPv6 host is activated in an IPv6 domain, it employs 
the technique known as Neighbourhood Discovery (ND) . 
to find out the identity of hosts with whom it can com- 
municate directly. It broadcasts an ND message con- 
taining its IPv6 network address, and each host that re- 
ceives it sends a reply message containing that host's 
I Pv6 network address. Since the domain uses an under- 
lying transport mechanism, say Ethernet using media 
access control (MAC) addresses, each host receiving 
the ND message will retrieve the new host's IPv6 net- 
work address and also the MAC address of the new 
host, and the new host will retrieve from each reply mes- 
sage the sending host's IPv6 network address and its 
MAC address. 

[0020] The new host now constructs an ND table in 
which each entry corresponds with a neighbouring host 
and comprises a first part in the form of the 128 bit IPv6 
address of that neighbouring host, and a second part in 
the form of the associated MAC address. 
[0021] The interface device (containing the protocol 
converter) between that IPv6 domain and an adjacent 
IPv4 domain will also have received the ND message 
and sent a reply message, and the new host will have 
made a special Default entry in the ND table having its 
first part formed by 128 zeros (in variants, these are all 
ones) and its second part formed by the MAC address 
of that interface device. 

[0022] Thus, when that new host wants to send a 
message to one of the other hosts in its domain, it con- 
structs an IPv6 message and accesses its ND table to 
retrieve the MAC address associated with the destina- 
tion address. The message is then encapsulated within 
an Ethernet packet in known manner and sent via the 
underlying Ethernet transport mechanism to the desti- 
nation host. 

[0023] If, on the other hand, the host constructs an 
IPv6 message having its destination address in the form 
of an IPv4-compatible or IPv4-mapped address, i.e. a 
message intended for an IPv4 host in the adjacent IPv4 
domain, this destination address will not be found in the 
ND table. In this situation, the accessing algorithm will 
return the MAC address of the Default entry, and the 
message will be sent to the protocol converter. 
[0024] Protocol converters can only convert (or trans- 
late) between corresponding fields of the headers of the 
IPv6 and IPv4 messages. Where a field in the header 
of, say, an IPv6 message has no corresponding field in 
the header of an IPv4 message, or vice versa, the infor- 
mation in that field will be lost in the protocol conversion 
process. 

[0025] As mentioned above, tunnelling techniques 
are known for enabling IPv6 hosts to communicate 
amongst themselves when they are in spaced-apart do- 
mains. In this case, the interface device contains a tun- 
nelling mechanism instead of a protocol converter. It will 
be appreciated that before now, for an IPv6 host to be 



able to communicate both with IPv4 hosts and with re- 
mote IPv6 hosts, it was necessary forthat IPv6 host and 
the domain interface to be dual stack, i.e. having both 
IPv4 and IPv6 communication capability. If an IPv6 host 
s was not dual stack, its accessing algorithm would return 
only a single MAC address for the Default entry. This 
would be the MAC address of the input port of a protocol 
converter, if the network administration had decided that 
the IPv6 host is to be able to communicate with IPv4 
io hosts, or it would be the MAC address of the input port 
of a tunnelling mechanism, if the network administration 
had decided that the IPv6 host is to be able to commu- 
nicate with IPv6 hosts. That Default entry MAC address 
could not be a common input address for both the pro- 
's tocol converter and the tunnelling mechanism. 

[0026] Methods of tunnel establishment in accord- 
ance with the present invention are advantageous in 
that the source host need only send a standard address 
request message in its own protocol, e.g. if the first net- 
20 work transmission protocol is IPv6 then that message 
will be an IPv6 DNS address request message, and the 
establishment of the tunnel across the intervening IPv4 
domain is automatic and completely autonomous, re- 
quiring nothing special from the source host. Thus, a 
25 company that has an existing IPv4 domain can make 
the transition from full IPv4 implementation to full IPv6 
implementation by introducing isolated IPv6 domains 
using standard IPv6 technology. 
[0027] Specific embodiments of the present invention 
30 will now be described with reference to the drawings in 
which: 

Figure 1 is a schematic diagram of an IPv4 domain 
interfaced with two isolated IPv6 domains; 
35 Figure 2 is a schematic diagram of a border router; 
Figure 3 is a schematic diagram of an IPv6 DNS 
Response message; 

Figure 4 is a schematic diagram of an IPv4 DNS 
Response message resulting from conversion of 
40 the IPv6 DNS Response message of Figure 3; 

Figure 5 is a schematic diagram of an IPv6 DNS 
Response message resulting from conversion of 
the IPv4 DNS Response message of Figure 4; and 
Figure 6 is a schematic diagram showing the format 
45 of special IPv6 addresses used with the 6to4 tun- 
nelling technique. 

[0028] In Figure 1 , an I Pv4 domain 1 0 separates a first 
IPv6 domain 12, constituting in accordance with the 

so present invention a first network operating in accord- 
ance with a first transmission protocol and having net- 
work addresses in accordance with a first addressing 
convention, from a second IPv6 domain 14, constituting 
in accordance with the present invention a third network 

55 also operating in accordance with the first transmission 
protocol and having network addresses in accordance 
with the first addressing convention. Hosts in the IPv4 
domain 1 0 are IPv4 only, and hosts in the IPv6 domains 
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1 2 and 1 4 are IPv6 only. The IPv4 domain 1 0 constitutes 
in accordance with the present invention a second net- 
work operating in accordance with a second transmis- 
sion protocol and having network addresses in accord- 
ance with a second addressing convention. For simpli- 5 
tying the drawings, no IPv4 hosts are shown, and in 
each of the IPv6 domains 12 and 14 only one IPv6 host 
(28 and 30, respectively, as referred to later) is shown. 
[0029] The first IPv6 domain 12 is connected to the 
IPv4 domain 10 via a border router 16A, also referred 
to as an ingress interface with respect to the first IPv6 
domain 12 and constituting an interface of the present 
invention. The second IPv6 domain 14 is connected to 
the IPv4 domain 10 via a border router 16B, also re- 
ferred to as an egress interface with respect to the first 
IPv6 domain 12. The border router 16B is identical to 
the border router 16A. 

[0030] The IPv4 domain 10 contains a complete do- 
main name system (DNS) 20 including a plurality of DNS 
servers 22, of which only two DNS servers 22A and 22B 
are shown, and the IPv6 domains 12 and 14 contain re- 
spective DNS servers 24 and 26. 
[0031] Suppose that a host 28 in the first IPv6 domain 
12 wishes to send a packet to a host 30 in the second 
IPv6 domain 14. Thus, for this transaction, the host 28 
is referred to as the source host 28 and the host 30 is 
referred to as the destination host 30 . 
[0032] The source host 28 knows the name of the des- 
tination host 30, so it constructs in known manner an 
I Pv6 DNS Request message (not shown) requesting the 
IPv6 address of the destination host 30 . The source 
host 28 sends this DNS Request message as a recur- 
sive request to its local DNS server, which in this em- 
bodiment is the DNS server 24. The DNS server 24 will, 
in known manner, send a number of iterative DNS Re- 
quest messages (not shown) to the DNS 20 until it learns 
about the DNS server 26. Finally, a DNS Request mes- 
sage (not shown) will go to the DNS server 26 request- 
ing the IPv6 address of the destination host 30. As the 
DNS request passes from the first IPv6 domain 12 
through the border router 16A to the IPv4 domain 10, it 
is processed by a protocol converter (PC) 32A (see Fig- 
ure 2) and undergoes IPv6/IPv4 translation. Corre- 
spondingly, as the DNS request passes from the IPv4 
domain 10 through the border router 16B to the second 
IPv6 domain 14, it is processed by a protocol converter 
32 B and undergoes IPv4/IPv6 translation. 
[0033] The protocol converters 32A and 32B conform 
to a specification known as Network Address Transla- 
tion-Protocol Translation (NAT-PT). They translate be- 
tween IPv4 and IPv6 addresses and keep state during 
the time of the session, and translation between IPv4 
and IPv6 DNS Request messages and DNS Response 
messages, including translation of IP headers and DNS 
payload information is controlled by an application layer 
gateway (ALG). In the art, an alternative term for a DNS 
Response message is a DNS Answer message. 
[0034] For more detailed information the reader can 



obtain from the Internet Engineering Task Force (IETF), 
the document known as draft-ietf-ngtrans-natpt-05.txt, 
or any variant thereof, "Network Address Translation - 
Protocol Translation (NATPT)", by G. Tsirtsis and P. 
Srishuresh. 

[0035] The DNS server 26 responds to the DNS Re- 
quest message for the IPv6 address of the destination 
host 30 with a IPv6 DNS Response message 34 (see 
Figure 3) having a conventional format of destination ad- 
dress field 36, source address field 38, and response 
address record 40 that contains the IPv6 address of the 
destination host 30. 

This IPv6 DNS Response message 34 travels through 
the second IPv6 domain 14 to the border router 16B 
where it becomes converted to an IPv4 DNS Response 
message 42 (see Figure 4) comprising destination ad- 
dress field 44, source address field 46. response ad- 
dress record 48 and, in accordance with the present in- 
vention, additional records 50 and 52, and this message 
42 travels through the IPv4 domain 1 0 to the border rout- 
er 1 6A where it becomes converted to an IPv6 DNS Re- 
sponse message 54 comprising destination address 
field 56, source address field 58 and response address 
record 60, and sent to the source host 28. The route that 
the DNS Response message (in its various forms, i.e. 
34, 42 and 54) takes in the domains 10, 12 and 14 de- 
pends on the DNS configuration in each of the domains, 
but it will have to pass through the border router 1 6B 
and the border router 16A in that order. 
[0036] For convenience, the terms "field" and "record" 
are used synonymously and interchangeably in this de- 
scription, although in the art a field is generally taken to 
be a component part of a record. 
[0037] When the IPv6 DNS Response message 34 is 
received by the border router 16B via its IPv6 network 
interface controller 62B, it is fed in parallel to the protocol 
converter 32B and to a controller 64B, and also to an 
encapsulator 86B and a 6to4 encapsulator 90B. The 
controller 64B is connected via a control line 65A to con- 
trol inputs of the protocol converter 32B, the encapsu- 
lator 86B and the 6to4 encapsulator 90B and by placing 
a suitable address on the control line 65A selects the 
appropriate one of these devices. 
[0038] The controller 64B (i) recognises that the re- 
ceived message is a DNS Response message and en- 
ables the protocol converter 32B, (ii) retrieves the IPv6 
address from the response record 40 and writes this 
message to a storage location 66B formed by part of its 
internal memory 68B; (iii) writes the IPv4 address of the 
border router 16B, i.e. the IPv4 address of the tunnel 
terminating endpoint on the border router 1 6B, to a stor- 
age location 70B also formed by part of its internal mem- 
ory 68B; (iv) receives from the protocol converter 32B 
the converted DNS Response message 42; appends 
the content of the storage location 70B as the first addi- 
tional record 50, and the content of the storage location 
68B as the second additional record 52; and (v) sends 
the resulting IPv4 DNS Response message 42 to an 
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IPv4 network interface controller 72B for transmission 
over the IPv4 domain 10 to the border router 16 A. 
[0039] In a variant, the received IPv6 DNS Response 
message 34 is fed only to the controller 64B, which 
writes this message to a storage location 74B formed s 
by part of its internal memory 68B. The controller 64B 
then (i) retrieves the IPv6 address from the response 
record 40 and writes this message to the storage loca- 
tion 66B; (ii) writes the IPv4 address of the border router 
16B to the storage location 70B; (iii) generates a modi- 10 
fied IPv6 DNS Response message by retrieving the con- 
tent of the storage location 66B and appending the con- 
tent of the storage location 70B as the first additional 
record 50, and the content of the storage location 66B 
as the second additional record 52; and (iv) sends this 
modified IPv6 DNS Response message to the protocol 
converter 32B. The ALG of the protocol converter 32 
processes only the header and address response 
record of the DNS Response message to produce the 
resulting IPv4 DNS Response message 42, i.e. it allows 
the additional records to remain unchanged. 
[0040] It will be appreciated that the feeding of the re- 
ceived message directly to the protocol converter 32B, 
and the sending of an enabling signal on the control line 
65A to the protocol converter 32B by the controller 64B 
is logically equivalent to the sending of the received 
message to the protocol converter 32B by the controller 
64B in the above variant, and constitutes sending the 
message to the protocol converter 32B in accordance 
with the present invention. 

[0041] When the IPv4 DNS Response message 42 is 
received by the border router 16A via its IPv4 network 
interface controller 72A, it is fed in parallel to the protocol 
converter 32A and to a controller 64A. 
[0042] The controller 64A (i) receives from the proto- 
col converter 32A the output IPv6 DNS Response mes- 
sage comprising destination address field 56, source 
address field 58, response address record 60, and ad- 
ditional records 50, 52; and (ii) retrieves the IPv6 ad- 
dress from the second additional record 52, i.e. the true 
IPv6 address of the destination host 30, and inserts it 
into the response address record 60 of that output mes- 
sage instead of the IPv4-compatible IPv6 address for 
the destination host 30, which the protocol converter 
32A had generated. The controller 64 A then strips off 
the additional records 50, 52, and sends the resulting 
IPv6 DNS Response message 54 (see Figure 5) to an 
IPv6 network interface controller 62A of the border rout- 
er 1 6A for transmission to the source host 28. 
[0043] Additionally, the controller 64A is arranged to 
retrieve the IPv4 address of the tunnel terminating end- 
point from the first additional record 50, to create a map- 
ping of the IPv6 address of the destination host 30 to 
the address of the IPv4 tunnel terminating endpoint, and 
to store this mapping, i.e. create an entry, in an IPv6/tun- 
nel endpoint table 76A formed by part of an internal 
memory 68A of the controller 64A. This table is referred 
to as a look-up table. 



[0044] In a variant, the additional records 50, 52 are 
stripped from the DNS Response message prior to the 
retrieval of their contents. In another variant, the addi- 
tional records remain attached to the DNS Response 
message, but this is not as efficient as stripping the ad- 
ditional records. In this present embodiment, each entry 
in the IPv6/tunnel endpoint table 76A comprises a first 
element 78A comprising the IPv6 address of a corre- 
sponding destination host 30, a second element 80A 
comprising the IPv4 address of the tunnel terminating 
endpoint, i.e. of the border router 16B, and third and 
fourth elements 82A and 84A, to be described later. 
[0045] Upon receipt of the resultant IPv6 DNS Re- 
sponse message 54, the source host 28 retrieves the 
IPv6 address from its address record 60 and stores it in 
its internal memory for use in sending data packets to 
the destination host 30. 

[0046] In known manner, the source host 28 gener- 
ates for each of these data packets a header including 
a source address field and a destination address field, 
and writes the retrieved IPv6 address into the destina- 
tion address field. 

[0047] Upon receipt of each of these data packets at 
the border router 1 6A, the controller 64A retrieves the 
destination address, and, in accordance with the re- 
trieved destination address, accesses the IPv6/tunnel 
endpoint table 76 A. If there is a match with the contents 
of a first element 78A of an entry, the controller 64A re- 
trieves the corresponding IPv4 tunnel terminating end- 
point from the second element 80A of that entry, and 
commands an encapsulator 86A to encapsulate the 
packet in an IPv4 packet addressed to the border router 
1 6B using the retrieved IPv4 tunnel terminating endpoint 
address. In this embodiment, the encapsulator 86A is 
arranged to receive the packet directly from the IPv6 
network interface controller 62 A of the border router 
16A, but it does not perform encapsulation until com- 
manded by the controller 64A. In a variant, the controller 
64A receives the packet directly from the IPv6 network 
interface controller 62A and passes it to the encapsula- 
tor 86A if there is a match. In practice, when the border 
router 1 6A receives a packet the controller 64A writes it 
into a storage location of its internal memory 68A, and 
the controller 64A will pass to the encapsulator 86A the 
address of the relevant storage location, together with 
an instruction for the encapsulator 86A to access that 
storage location. 

[0048] Upon receipt of the encapsulating IPv4 packet 
at the border router 1 6B, an un -encapsulator 88B of the 
border router 16B strips off the IPv4 header and re- 
trieves the payload of that IPv4 packet, i.e. un-encap- 
sulates the original IPv6 packet from the source host 28, 
and sends that IPv6 packet to the destination host 30. 
The controller 64B also creates a mapping (in its 
IPv6/tunnel endpoint table 76B) of the IPv6 address of 
the source host 28 and the tunnel originating endpoint, 
i.e. the IPv4 address of the originating border router 
16A, these being respectively retrieved from the source 
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address field of the IPv6 header and the source address 
field of the IPv4 header. 

[0049] When the destination host 30 returns a Reply 
packet, a controller 64B of the border router 16B re- 
trieves the destination address, "IPv6 host 28", from the 5 
received Reply packet, accesses its IPv6/tunnel end- 
point table 76B in accordance with the retrieved desti- 
nation address (i.e. seeking a matching element 78B), 
retrieves the corresponding IPv4 address (element 
80B), and commands an encapsulator 86B to encapsu- 
late the Reply packet in an IPv4 packet addressed to an 
un-encapsulator 88A of border router 16A using the 
IPv4 tunnel originating endpoint address just retrieved 
from the element 80B of the IPv6/tunnel endpoint table 
76B. Upon receipt of this IPv4 packet at the border rout- 
er 1 6A, the un-encapsulator 88A performs un-encapsu- 
lation to retrieve the Reply packet, and the border router 
1 6A then sends the retrieved Reply packet to the source 
host 28. 

[0050] The source host 28 and the destination host 
30 are now in a session in which IPv6 packets pass be- 
tween them via the tunnel just established between the 
border routers 1 6A and 1 6B. 

[0051] The above described mechanism provides for 
an IPv6 host, which is in an isolated IPv6 domain, to 
communicate with another IPv6 host, which is in another 
isolated IPv6 domain, via an intermediate IPv4 domain, 
without any knowledge of where that other IPv6 host is, 
and without the source IPv6 host needing to do anything 
different from a standard communication procedure with 
another IPv6 host within its own IPv6 domain. The DNS 
server local to the source IPv6 host makes a Request 
via the IPv4 domain to the IPv6 DNS server that is on 
the same network as the destination IPv6 host, and the 
border routers automatically set up respective map- 
pings associating the tunnel endpoint and the IPv6 ad- 
dress of the IPv6 hosts behind the border routers. 
[0052] In this embodiment, the host 28 stores the ad- 
dress retrieved from the DNS Response for a short time. 
The host 28 records the time at which the address is 
stored and deletes that stored address twenty four hours 
later. Alternatively, other methods can be employed, e. 
g. the address can be deleted at midnight, when the day 
changes, or the address can be stored with a "time to 
live" value which is the start value of a count down timer. 
Similarly, the border router 16A deletes the entry in its 
IPv6/tunnel endpoint table 76A after a short time. By 
preventing permanent storage of the address of the host 
30, this avoids the risk that the tunnel terminating end- 
point becomes out of date for transmissions to the host 
30, e.g. the border router 1 6B is out of service, and that 
the border router 16A continues to send encapsulated 
packets to that out of date address. In a variant, the ad- 
dress is deleted after transmission of the last packet of 
the session. The intent of all the above alternatives is, 
to a greater or lesser extent, to ensure that tunnels 
across the IPV4 domain 10 are always up to date. 
[0053] In alternative embodiments, some of the en- 



tries in the lPv6Aunnel endpoint table 76A can be cre- 
ated by the administrative personnel of the network op- 
erator. This is known as manual configuration of a tun- 
nel, and the tunnel is permanent until changed at a later 
date by the administrative personnel. 
[0054] As shown in Figure 2, the border router 16A 
also comprises a 6to4 tunnelling encapsulator 90A (and 
6to4 tunnelling un-encapsulator 92A) and can thus in- 
terwork with a border router which is similarly enabled, 
although in variants these may be omitted. The special 
IPv6 addresses 94 (see Figure 6) used for this technique 
have a three-part format of which a first part 96 having 
thirty two bits is a prefix uniquely identifying that the 
packet is to be tunnelled by the 6to4 tunnelling tech- 
nique, a second part 98 having thirty two bits is the IPv4 
address of the 6to4 tunnel endpoint, and the third part 
100 having sixty four bits is known as the interface ID 
which is the modified MAC address of the destination 
host. In variants having a different tunnelling encapsu- 
lator, a different respective prefix is used for the same 
purpose. 

[0055] In some variants of these embodiments, the 
controller 64A is arranged to recognise the presence of 
this prefix within the retrieved destination address of a 
received packet and to command the 6to4 tunnelling en- 
capsulator 90A to handle the received packet, and in 
this case the 6to4 tunnelling encapsulator 90A is ar- 
ranged to retrieve the special IPv6 address and to ex- 
tract from its second part 98 the IPv4 address of the 6to4 
tunnel endpoint. 

[0056] Where, as mentioned above, the controller 
64A is arranged to perform prefix recognition, the prefix 
to be recognised is stored in a storage location of its 
internal memory 68A, and this storage location can be 
an entry or part of an entry of the IPv6/tunnel endpoint 
table 76A. 

[0057] The un-encapsulators 88B and 92B have re- 
spective IPv4 addresses, which are used by the corre- 
sponding e neaps ulators 86A and 90A in generating their 
respective encapsulated packets. 
[0058] In the preferred arrangement of border router 
having a plurality of different encaps ulators, e.g. 86, 90, 
the controller 64 A accesses the IPv6/tunnel endpoint ta- 
ble 76A in accordance with a set of match criteria to cov- 
er the range of possible situations. These are 

(a) a tunnel has already been established by the 
above described DNS Request technique and a 
IPv6 destination-specific IPv6/lPv4 entry exists in 
the IPv6/tunnel endpoint table 76A; 

(b) a tunnel has already been established by one of 
the known tunnelling techniques and an IPv6/IPv4 
entry exists in the IPv6/tunnel endpoint table 76A, 
of which the first element 78A has a first part in the 
form of a specific prefix corresponding to that tun- 
nelling technique; 

(c) network management personnel have manually 
configured the border router 16 to define a tunnel 
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to a specific IPv6 destination host using 6to4 (or 
6over4) to another border router (which might be 
the border router 1 6B or a different border router 
(not shown) associated with a further IPv6 domain 
(not shown)), and for this case the IPv6/tunnel end- s 
point table 76A has an entry whose first element 
78A is the IPv4-compatible (or IPv4-mapped) ad- 
dress of that destination host; 

(d) network management personnel have manually 
configured the border router 16A to define a tunnel 
to unspecified IPv6 destination hosts using 6to4 (or 
6over4) to another border router (which might be 
the border router 1 6B or a different border router 
associated with a further IPv6 domain), and for this 
case the IPv6/tunnel endpoint table 76A has an en- 
try having its first element 78A in the form of the 
6to4 (or 6over4) prefix followed by the IPv4 address 
of that other border router followed by null charac- 
ters, and in some variants the second element 80A 
of this entry contains null characters, whilst in yet 
other variants the second element 80A of this entry 
contains the IPv4 address of that other border rout- 
er; and 

(e) the table contains an entry whose first element 
78A is a generic IPv4-compatible or IPv4-mapped 
IPv6 address, i.e. its first eighty bits are all zeros 
and the final thirty two (or in a variant, forty eighty) 
bits are null characters (zeros), the second and 
fourth elements 80A and 84A contain null charac- 
ters, and a third element 82A contains the identifier 
-PC". 

[0059] The controller 64A uses its IPv6/tunnel end- 
point table 76A to determine the appropriate handling of 
a received packet in the following manner. 
[006O] If the controller 64A finds an entry having a first 
element 78A matching the complete retrieved destina- 
tion address, then the content of the second element 
80A of that entry is retrieved and used as the IPv4 des- 
tination address, i.e. that of the border router 16B, the 
tunnel endpoint. Additionally, the content of the third el- 
ement 82A of that entry is retrieved and used as a check 
that the retrieved IPv4 destination address and the 
packet received by the border router 1 6 A are to be proc- 
essed by the encapsulator 86A. The content of the third 
element 82A is either an identifier for an encapsulator 
86A, 90A (e.g. "EN") or an identifier for the protocol con- 
verter 32A (e.g. "PC"). As a further check, the fourth el- 
ement 84A of that entry contains an identifier for the en- 
capsulation type. In other words, for an entry matching 
the complete retrieved destination address, as just de- 
scribed, the encapsulation type identifier will be "DNS" 
to signify that the encapsulator 86A is to be used. 
[0061] If the controller 64A finds an entry whose first 
element 78A has the first thirty two bits matching the first 
thirty two bits, i.e. the special 6to4 prefix part, of the re- 
trieved destination address, then the third and fourth el- 
ements 82A and 84A of that entry are checked ("EN" 



and "6to4 u , respectively), the IPv4 destination address 
is retrieved from the second element 80A of that entry 
and sent with the packet received by the border router 
16A to be processed by the encapsulator 90A. 
[0062] If the retrieved destination address is either 
!Pv4-compatible or IPv4-mapped, i.e. the packet is to 
be protocol converted for an IPv4 destination, then its 
first eighty bits will be all zeros, and the following sixteen 
bits will be either all zeros if the address is IPv4-com- 
patible, or all ones if the address is IPv4-mapped. Thus 
the controller 64A checks to see whether its IPv6/tunnel 
endpoint table 76A contains an entry whose first ele- 
ment 78A has its first eighty bits all zeros The content 
of the second element 80A of such an entry will be all 
null characters, because no tunnel is involved, and the 
content of the fourth element 84A of such an entry will 
be all null characters, because no encapsulation is in- 
volved. The content of the th ird element 82A of that entry 
is retrieved and used as a check that the retrieved IPv4 
destination address and the packet received by the bor- 
der router 1 6A are to be processed by the protocol con- 
verter 32A. In this case, the content of the third element 
82A is an identifier for the protocol converter 32A (e.g. 
"PC"). 

[0063] In other variants, the controller 64A is arranged 
to access the IPv6/tunnel endpoint table 76A, as before, 
and only command the 6to4 tunnelling encapsulator 
90A upon detecting a match with an entry, and in this 
case the controller 64A passes the special IPv6 address 
to the 6to4 tunnelling encapsulator 90A, or alternatively 
the controller 64A extracts the IPv4 address of the 6to4 
tunnel endpoint and passes it to the 6to4 tunnelling en- 
capsulator 82A, or yet again the controller 64A, upon 
detecting such a match, retrieves the element 80A of 
the matching entry. This element 80A contains the IPv4 
address of the 6to4 tunnel endpoint, which was inserted 
into that element 80A by the controller (or manually) up- 
on creation of that entry. 

[0064] In the above embodiment, the local DNS serv- 
er for the source host 28 is the IPv6 DNS server 24, but 
in alternative embodiments it can be one of the IPv4 
servers 22 of the DNS 20. In such alternative embodi- 
ments, although the host 28 can send a DNS Request 
message for obtaining the IPv6 address of the host 30 
and. by the present invention, establish a tunnel across 
the IPv4 domain 10, the situation is not symmetrical in 
that the host 30 cannot act as a source and establish a 
corresponding tunnel across the IPv4 domain 10 to the 
host 28. For an IPv6 host to be contactable, i.e. act as 
destination, by the method of the present invention, it is 
necessary for the DNS server local to that IPv6 host to 
be an IPv6 DNS server on the same IPv6 domain as that 
IPv6 host, because the DNS Response message has to 
pass through the border router adjacent to that IPv6 host 
in order that the tunnel can be established. In other 
words, the DNS Request message has to pass through 
the IPv4 domain and not stop at an IPv4 DNS server 
acting as the local DNS server for the intended destina- 
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tion IPv6 host. 



Claims 

1 . A method of establishing a tunnel from a first inter- 
face between a first network and a second network 
to a second interface between the second network 
and a third network, the first and third networks op- 
erating in accordance with a first transmission pro- 
tocol and having addresses in accordance with a 
first addressing convention, and the second net- 
work operating in accordance with a second trans- 
mission protocol and having addresses in accord- 
ance with a second addressing convention, the tun- 
nel being for the transport of messages from a first 
host on the first network to a second host on the 
third network, the method comprising the steps of: 

sending from the first host an address request 
message in accordance with the first transmis- 
sion protocol, referred to herein as a first type 
address request message, containing the 
name of the second host; 
upon receipt of the address request message 
at a name to address conversion system of the 
third network, returning an address response 
message in accordance with the first transmis- 
sion protocol, referred to herein as a first type 
address response message, and containing 
the address of the second host in a response 
address field; 

upon receipt of that first type address response 
message at the second interface, 

converting it to an address response mes- 
sage in accordance with the second trans- 
mission protocol, referred to herein as a 
second type address response message, 
and 

augmenting that converted second type 
address response message by fields re- 
spectively containing the address of the 
second interface in accordance with the 
second addressing convention and the ad- 
dress of the second host in accordance 
with the first addressing convention; and 

upon receipt of that augmented that converted 
second type address response message at the 
first interface, 

converting it to a first type address re- 
sponse message, 

retrieving the contents of the augmenting 
fields, 

storing at the first interface a mapping of 
the retrieved address of the second host 



and the retrieved address of the second in- 
terface for use in encapsulating messages 
from the first host addressed to the second 
host, and 

5 replacing the content of the response ad- 

dress field of the resulting first type address 
response message by the retrieved ad- 
dress of the second host. 

id 2. A method as claimed in claim 1 , wherein for estab- 
lishing a tunnel in the reverse direction for the trans- 
port of messages from the second host to the first 
host, the method comprises the further steps of: 

is upon receipt at the first interface of a message 

from the first host addressed to the second 
host, encapsulating that received message in 
accordance with the first mapping; and 
upon receipt of the encapsulated message at 

20 the second interface, 

un-encapsulating that received encapsu- 
lated message, 

retrieving from the encapsulating header 
25 the address of the first interface in accord- 

ance with the second addressing conven- 
tion, 

retrieving from the un-encapsulated mes- 
sage the address of the first host in accord - 
30 ance with the first addressing convention, 

and 

storing at the second interface a mapping 
of the retrieved address of the first host and 
the retrieved address of the first interface 
35 for use in encapsulating messages from 

the second host addressed to the first host. 

3. A method as claimed in either claim 1 or claim 2, 
including setting a time to live for a said stored map- 

40 ping, and rendering that stored mapping unuseable 
upon the expiry of the time to live. 

4. A method as claimed in claim 3, wherein the ren- 
dering step deletes that stored mapping. 

45 

5. A method of sending packets from a first host on a 
first network via a second network to a second host 
on a third network, the first and third networks op- 
erating in accordance with a first transmission pro- 

50 tocol and having addresses in accordance with a 
first addressing convention, and the second net- 
work operating in accordance with a second trans- 
mission protocol and having addresses in accord- 
ance with a second addressing convention, com- 

55 prising the steps of: 

establishing a tunnel from a first interface be- 
tween the first network and the second network 
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to a second interface between the second net- . 
work and the third network in accordance with 
the method of claim 1 ; 

upon receipt by the first host of the resulting first 
type address response message from the first s 
interface, retrieving the content of the response 
address field; 

generating one or more packets for transmis- 
sion having a header including source and des- 
tination address fields, the source address field 10 
containing the address of the first host.and the 
destination address field containing the re- 
trieved content of the response address field; 
sending the or each generated packet to the 
first interface; « 
for the or each said generated packet received 
by the first interface, accessing the stored map- 
pings in accordance with the destination ad- 
dress of the received generated packet, 

20 

retrieving the stored interface address of 
the mapping whose retrieved host address 
matches the destination address of the re- 
ceived generated packet, 
generating an encapsulated packet having 25 
a pay load formed by the received generat- 
ed packet, and having a header including 
source and destination address fields, the 
source address field containing the ad- 
dress of the first interface, and the destina- 30 
tion address field containing the retrieved 
interface network address, 
sending the encapsulated packet to the 
second interface; and 

35 

for the or each encapsulated packet received 
by the second interface,' un-encapsulating the 
received encapsulated packet to recover the 
original generated packet forming its payload, 
and 40 

sending that recovered packet to the sec- 
ond host. 



and a third network, the method being substantially 
as hereinbefore described with reference to the 
drawings. 

10. A method of sending packets from a first host on a 
first network via a second network to a second host 
on a third network, the method being substantially 
as hereinbefore described with reference to the 
drawings. 



A method as claimed in claim 5, including the step 
of storing the retrieved content in association with 45 
the name of the second host. 



A method as claimed in claim 6, including the steps 
of setting a time to live for the stored retrieved con- 
tent, and rendering that stored retrieved content un- so 
useable upon the expiry of the time to live. 

A method as claimed in claim 7, wherein the ren- 
dering step deletes the stored retrieved content. 

55 

A method of establishing a tunnel from a first inter- 
face between a first network and a second network 
to a second interface between the second network 



10 



EP 1 087 575 A1 




11 



EP 1 087 575 A1 



16. 



32 



62 

1 

IPV6 
NIC 



< ► 



65. 



86 



88 



90 



92 



64. 



68. 



72 



_} 

IPV4 
NIC 



66 



70 



74 



76, 



78 


80 


82 


84 











Fig. 2 



EP 1 087 575 A1 




13 



EP 1 087 575 A1 



r 



r 



CD 



r 



CO 



r r 



CM 



O 

in 



r 



go 



co 

CO 

LU 

cc 

Q 
< 



-J Q 



CO $ Q 
^ [1] CC 
O QT O 
Q- Q O 
CO q UJ 
LU ^ DC 



CO ^ O 

Eta 

U- Q UJ 

< 



Is 

10 CO Q 

< 



Q 
CC 
O 
O 



14 



EP 1 087 575 A1 



r 



CO 

in 



r 



oo 

LO 



r 



to 



r 



O 
CD 







to 




LU 
OC 




Q 




Q 




< 








o 








< 




Z 




I — 




CO 




LU 

Q 




CO 




CO 




UJ 

DC 




Q 




Q 




< 




LU 

u 




GC 




Z> 




o 




CO 




. CO CO 




PON 
)RES 


ORD 


CO £ 
LU Q 


o 

LU 


OC < OC 



LO 



15 



EP 1 087 575 A1 



r 



CD 



r 



to 



16 



EP 1 087 575 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



EP 99 30 7550 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document wKh indication, where appropriate, 
of rdevanj passages 



Relevant 
to claim 



CLASS F1CATION OF THE 
APPLICATION (IW-CI.7) 



US 5 802 285 A (HIRVINIEMI SEPPO) 
1 September 1998 (1998-09-01) 

* abstract * 

* page 2, right-hand column, line 13 - 
page 3, left-hand column, line 28 * 

LAB0RDE D: "UNDERSTANDING AND 
IMPLEMENTING EFFECTIVE VPNS" 
COMPUTER TECHNOLOGY REVIEW, US, WESTW0RLD 
PRODUCTION CO. LOS ANGELES, 
vol. 18, no. 2, 

1 February 1998 (1998-02-01), page 
12,14,16 XP000733729 
ISSN: 0278-9647 

* the whole document * 

EP 0 840 482 A (HITACHI LTD) 
6 May 1998 (1998-D5-06) 

* claims * 



1-10 



1-10 



H04L12/46 



TECHNICAL FIELDS 

(lnt.CI.7) 



H04L 



The present search report has been drawn up for all claims 



THE HAGUE 



22 September 2000 



Perez Perez, J 



CATEGORY OF CITED DOCUA^NTS 
X : particularly relevant if taken aJone 

Y : particularly relevant rf combined with another 

cocument of the same category 
A : technological background 
O : non-written dledoeure 
P: 



T : theory or princioie underlying the invention 
E : earlier patent document, but published on. or 

after the fling oate 
D : document cited in the application 
L : document died for other reasons 

& : member of the same patent family, corresponding 



17 



EP 1 087 575 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 99 30 7550 



This annex Dsts the patent family mam bars relating to the patent documents cited In the above-mentioned European search report. 
The members are as contained In the European Patent Office EOP file on 

The European Patent Office is rn no way liable for these particulars which are merely given for the purpose of Information. 

22-09-2000 



Patent document 
died in search report 



Publication 



Patent family 
members) 



Publication 



US 5802285 



EP 0840482 



01-09-1998 



FI 
GB 



90710 B 
2267418 A,B 



30-11-1993 
01-12-1993 



06-05-1998 



JP 
JP 



10136052 A 
11055319 A 



22-05-1998 
26-02-1999 



i For more details about this annex : see Official Journal of the European Patent Office. No. 12/82 



18 



